Many programming environments allow for only one set of global names. If you define a global variable, the variable's name is available in all parts of the program at all times. If the program that contains a variable's definition is incorporated and compiled into another program, that variable name is visible to all parts of that new program as well, and may conflict with variables of the same name that are defined elsewhere.
ScriptX provides a level of indirection between names and variables. A variable is an association between a name and a location in memory-a location which stores a value. In ScriptX, that value is always a reference to an object. This association between a name and a value cell is called a name binding. A module can be thought of as a collection of name bindings.
Using ScriptX modules, a given location in memory can have different names in different parts of a program. A module is a device for resolving name conflicts, so that groups of programmers can collaborate on a project. Using modules, you can encapsulate your program as a unit, and specify which classes, objects, functions, and global variables are visible outside that unit. ScriptX modules allow code that is compiled and tested for one project to be reused in other projects.
Modules have one other important function in ScriptX. Although
the ScriptX class ModuleClass does not inherit
from Collection, a module is best understood as a
collection of name bindings. When a module is added to a title
container, it stores its name bindings for classes, objects,
functions, and variables to disk. This feature is useful as a
mechanism for storing and retrieving compiled classes,
functions, variables and objects.
Modules should not be confused with segmentation or dynamic
loading of objects. When the ScriptX bytecode compiler is
instructed to switch from one module to another, using the
in module expression, all objects defined while
executing in former module remain in memory. Any bindings that
exist in the former module still exist, and can be used when
that module becomes the current module again. Nor does loading
a new module load any objects that the new module defines. A
program must explicitly create or load any objects it
defines.
"Module Basics" on page 186 describes essential features of modules in ScriptX. Programmers who are new to ScriptX may want to read just this section and return to the remainder of the chapter at a later date. If you do not intend to define modules or save compiled code between programming sessions, you should find everything you need to know about modules in this section.
"Module Concepts" on page 188 continues the discussion in the previous section, exploring underlying ideas that are necessary for defining your own ScriptX modules.
"Defining and Using Modules" on page 196 presents the syntax for creating a module in ScriptX, and for switching the compiler environment between modules. This section defines all the syntax for importing and exporting names and variables between modules.
"Organizing Modules" on page 214 presents a conventional technique for using modules called the interface/implementation model. This model can be used to create larger networks of modules. It allows modules to be managed without the need for complex use relationships. If your program contains only a single module, and you do not intend for the code to be usable by others, you can skip this section and go on to the next.
"Storing Modules" on page 222 discusses how to structure your ScriptX program so that it can be saved more easily. Without modules, you must individually store each class and object that your program uses, and you must also reconstruct any global variables that the program requires. By encapsulating the program within a module, classes, objects, functions, and global variables in the program are automatically saved for you.
This document is part of the ScriptX Language Guide, one of the volumes of the ScriptX Technical Reference Series. ScriptX is developed by the ScriptX Engineering Team at Apple Computer, successor to the Kaleida Engineering Team at Kaleida Labs, Inc.